Add anchor outputs announcement blog post #214
Conversation
✅ Deploy Preview for lightningdevkit ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| Lightning channels rely on pre-signed transactions that its participants can broadcast to the | ||
| network if they wish to close the channel unilaterally, e.g., when their counterparty is offline. | ||
| Before the anchor outputs feature, participants continually negotiated their commitment | ||
| transaction’s fees based on the current blockspace demand to ensure a timely confirmation if they |
There was a problem hiding this comment.
Maybe "via the BOLT2 update_fee mechanism` if users desire to know more about legacy mechanism.
| Before the anchor outputs feature, participants continually negotiated their commitment | ||
| transaction’s fees based on the current blockspace demand to ensure a timely confirmation if they | ||
| were to be broadcast. This fee negotiation unfortunately came with its own set of problems. If | ||
| participants disagreed on the fees proposed for a channel, the channel became unusable due to a |
There was a problem hiding this comment.
I don’t know if unusable is the most correct term, rather “the channel would have been automatically shutdown”.
You might have issue when the channel become “stuck” / unusable because of wrong-estimation of the fee spikes reserve and the initiator do not have sufficient balance to add even an incoming HTLC output on the respective commitment transactions.
Quite nerdy as a distinction.
There was a problem hiding this comment.
Well it's still unusable, one is permanent and the other temporary. I think it's clear we're referring to the permanent one with "due to a unilateral close"?
| Child-Pays-For-Parent (CPFP) fee-bumping mechanism. A small portion of fees must still be allocated | ||
| to commitment transactions to ensure they can enter nodes’ mempools on their own. This will be | ||
| required until package relay is deployed network-wide, at which point we can have a fixed 1 sat/vB | ||
| commitment transaction and do away with the fee negotiation once and for all, eliminating the most |
There was a problem hiding this comment.
I’m not so sure we’ll kill the fee negotiation mechanism as it’s coming as the downside of increased fee-bumping reserve on both sides of the channel. Though better to raised this issue on the mailing list.
| open/accept more channels than its reserve is meant to handle, potentially resulting in a loss of | ||
| funds if any HTLCs need to be resolved onchain. In the meantime, application developers will need to | ||
| determine whether their use case warrants such enforcement and implement it themselves. For example, | ||
| a mobile user connected to a LSP could always defer to the LSP to broadcast the latest state such |
There was a problem hiding this comment.
I think a better example can be to say “a mobile user could always defer the fee-bumping of its commitment or HTLC transactions to a third-party watchtowers”.
Ideally you wouldn’t let the LSP with whom you have an opened channel be responsible of confirming your time-sensitive state, as they have a competing interest not to do so. However a crowd of watchtower sounds more adequate.
There was a problem hiding this comment.
What is this competing interest? They also provide a better UX by users being able to claim their balance immediately once the force close confirms.
| --- | ||
|
|
||
| Stay tuned for a [BitcoinDevelopers livestream](https://twitch.tv/BitcoinDevelopers) Thursday, | ||
| August 3rd at 4:00 PM UTC! Conor and Wilmer will be going over how to integrate anchor outputs into |
There was a problem hiding this comment.
Lol wen bitcoindevelopers livestream at the super bowl halftime to announce new LDK features :)
No description provided.